[レポート] Cloud-native .NET applications on AWS #reinvent #XNT402

いわさです。

YouTube で公開されている AWS re:Invent 2022 Breakout Session の Cloud-native .NET applications on AWS (XNT402) のセッションレポートです。

本セッションは既に YouTube にてアーカイブ動画が公開されていますので気になっていた方はそちらをチェックしてください。

本レポートでは見どころやポイントを抜粋して紹介しますので本編に興味を持って頂くきっかけになると嬉しいです。

セッション概要

Does your future include building cloud-native applications? In this session, learn how to design well-architected, modern .NET applications.
This includes building secure, scalable, low-cost serverless applications with tracing, debugging, testing, monitoring, CI/CD pipelines, and purpose-built databases.
Review a sample application, including full source code in GitHub, that showcases a reference architecture and how to design a .NET application on AWS.
This sample code includes Blazor, .NET Core, Amazon Cognito, Amazon ECS, Amazon API Gateway WebSocket APIs, AWS Step Functions with AWS Lambda, and Amazon DynamoDB.
Leave this session prepared for your future building modern cloud-native .NET applications on AWS.

スピーカー

• Brian Lewis, Solutions Architect, AWS
• Sanjay Gulati, Sr SA, App Modernization Lab, AWS

レベル

• 400 - Expert

セッション内容

このセッションではマイクロサービスサーバーレスなアーキテクチャーで最新の .NET テクノロジーを採用してアプリケーションを設計する方法を学ぶことが出来ます。
スライド少なめでスピーカー同士の掛け合いがおもしろかったです。

モダンアプリ

初めに AWS が定義するモダンアプリの定義について前提として触れています。

サービスごとに独立した高いスケーラビリティ、最適化された CI/CD、フォールトトレランスなどいくつかの特徴が挙げられていますが、モダンアプリは通常ビジネス上の様々な理由で採用されます。

モダンアプリ採用のユースケースなどに深く触れていませんが、このセッションでは以下のようなマイクロサービスサーバーレスな構成を例に挙げています。

フロントエンド

先程のアーキテクチャーを、大きくフロントエンドとバックエンドに分けてそれぞれに対して現時点での .NET 的にどういうアプローチを取ることが出来るのかについて言及されています。
AWS 的なサーバーレスだとかマイクロサービスだとかについてはあまりそこまで言及されていなくて、.NET の特定技術がこのアーキテクチャーとどう相性が良いのか、あるいはデメリットもあるのかなどが整理されています。

フロントエンドは CloudFront から SPA を配信する構成が取られています。
そして、ここでは Blazor で UI を構築しています。

Blazor は ASP.NET Core Blazor というもので JavaScript ではなく C# を使ってクライアント側ロジックを実装出来る技術です。
ここでは Blazor Web Assembly が前提になっていますが、Web Assembly 上に .NET ランタイムが構築されているものです。

ASP.NET Core MVC などと異なりサーバーサイドでのレンダリングが発生しないので、CloudFront で配信されるのでスケーラビリティを確保しやすく、また静的コンテンツなのでセキュリティ性も高いとのことです。
また、モダンアプリでは多様なクライアントに対応する必要がありますが、Blazor Hybrid という技術を使うことでモバイルアプリケーションやデスクトップアプリケーションで再利用しやすいアプリケーションを提供することが可能な点もメリットとして挙げられています。

ただ、現時点ではいくつかデメリットもあるのでこのあたりは注意しましょうと言及されていました。

• ブラウザーにダウンロードされる .NET ランタイムが含まれるのでアプリケーションサイズが大きくなりやすい。
  • ダウンロードが発生する際はクライアント側の開始時間が遅くなる
  • サイズには充分注意する必要がある。
• Blazor はサイレント認証に対応しているが Cognito ではサポートされていない
  • サイレント認証用のプロキシを導入することで統合が可能

Blazor では認証トークンを自動更新するサイレント認証がサポートされているようなのですが、今回のこの構成だと IdP に Cognito を採用しており、Cognito ではサポートされていないようです。
そこでこのサンプルアプリではサイレント認証用のプロキシを導入することでその問題を解決しているとのこと。
このセッションで使われているサンプルアプリも公開されているのでのちほど実装を確認してみたいと思います。

バックエンド

バックエンドについては主に Lambda で .NET 7 を採用する点について言及されていました。

前提として横にスケールできるように非同期サーバーレスでよく見るイベント駆動パターンが採用されています。
その中でいくつか Lambda 関数が登場するのですが、.NET 7 を採用するメリット・デメリットについて整理されていました。

内容の大半は .NET 7 の Native AOT に関するものです。
前提としてサーバーサイドはクロスプラットフォームである必要がないので .NET 7 の Native AOT が採用可能です。
Native AOT については re:Invent 2022 の以下のセッションでもう少し詳しく踏み込まれているのでそちらもご参照ください。

.NET 7 の Native AOT は AWS 内でもベンチマークをとっているそうです。
Native AOT によって従来の JIT によるオーバーヘッドがなくなるのでコールドスタート時間が大幅に改善されることは測定前からわかっていたそうです。
そして実際に測定してみるとコールドスタート時間はやはり改善されていましたのですが、しかし JIT と大きく変わらないだろうと思っていた実行時間についても大幅に改善されていたそうです。（AWS で使ったアプリだと 200 ~ 400% 速くなった）

これは Python や Go よりも速かったとのことで、セッション内では以下のような発言がありました。

「Java はもはや .NET の競合ではない。これからは Python や Go が .NET の競合になる。」

なかなか攻めた発言なのでブログには出さないほうがいいかもな？と思いました。
Native AOT は AWS の期待を超えたパフォーマンス向上になったということです。

Native AOT 採用時の注意事項

この Native AOT ですが何も考えずに採用出来るわけではなくいくつか注意事項があります。

• トリミング
  • Native AOT ではトリミングという動作で、事前コンパイル時に未使用のライブラリが削除されます。そのため、特にリフレクションなどの機構で実行時にロードされる類いのものは注意が必要です。後述の設定でトリミングオプションを設定する必要があります。
• ランタイムパッチ
  • Native AOT はマシンコードに変換されるので .NET ランタイムは不要になります。そのため毎月定期的に .NET はパッチが適用されますがそれらは .NET ランタイムが更新されたとしても Native AOT でコンパイル済みのバイナリには反映されません。
  • .NET ランタイムのパッチが配信される度に Native AOT バイナリの再コンパイルが必要です。
• ビルド時間
  • Native AOT はビルド時間が長くなりモジュールサイズも大きくなります。ビルドプロセスで充分なマシンパワーがあるかを通常よりも気をつける必要があります。

セッション内ではサードパーティライブラリに対してトリミングオプションの対象とするためのデモが紹介されています。
以下のように設定ファイルに対象ライブラリを含めてプロジェクトプロパティでオプションを有効化します。
詳細はアーカイブ動画のデモ部分をご確認ください。

オブザーバビリティ

最後にオブザーバビリティについての解説とデモもありました。
特にマイクロサービスの場合は分散されデバッグ情報が整理しにくくなるので X-Ray をこのセッションでは採用しています。

X-Ray を .NET に導入する方法は 2 ステップで実現可能で、NuGet で追加して初期化コードを追加するだけ。これはお手軽で良いですね。

そしてサーバーレスマイクロサービスの場合でもこのようにトレース情報からサービスマップまですぐに取得出来ます。

まとめ

このセッションでは現時点で .NET を採用するメリット・デメリットが整理されているのでとても良かったです。
AWS 3 割、.NET 7 割くらいって感じでしょうか。

ビジネス上のメリットデメリットはそこまで言及されておらず、今時点の AWS と .NET を組み合わせてモダンな感じで構成するとこうなるよというのがわかるセッションという感じですね。
1 年後とかになると、また .NET 8 や AWS の新サービスなどでトレンドや構成が変わりそうだとと思っていて、来年の re:Invent で同じようなセッションがあれば比較してみたいですね。